home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PsL Monthly 1993 December
/
PSL Monthly Shareware CD-ROM (December 1993).iso
/
prgmming
/
dos
/
c
/
ctrlc.exe
/
READ.ME
< prev
Wrap
Text File
|
1992-09-30
|
5KB
|
135 lines
Greetings,
I work for a small OEM of embedded process controls. This zip file
contains 'CTRLC.C', the quick-n-dirty Ctrl-Break & Ctrl-C intercept we use in
our systems, based on AT class motherboard. The file also contains the BIOS
int 15h intercept we use. Most of the info was gleaned from The Programmers PC
Sourcebook, by Thom Hogan, (the old blue one, not the error-ridden 2nd ed),
and verified in the AT tech ref, MS-DOS programmer's guide, etc.
Originally, we tried to handle Ctrl-Break via signal() calls.
The code looked something like this:
Boolean breakFlag = False;
void breakHandler()
{
signal( SIGINT, breakHandler );
breakFlag = True;
}
int main()
{
...
signal( SIGINT, breakHandler );
...
}
Problems with this approach were:
1. The handler had to be re-installed at each invocation. We found that
it was possible to generate Ctrl-Break or Ctrl-C fast enough to
bypass the handler, and dump the user back to dos. In our systems,
this is a safety hazard, not a mere nuisance. (The custom co-processor
is not informed of the shutdown, interrupt vectors remain hooked, etc)
2. There was no way to differentiate between a Ctrl-Break and a Ctrl-C.
We are presently treating these keys identically, but someday ...
We whipped up a quick-n-dirty ASM file to hook the BIOS int 1Bh, and
DOS int 23h. We (belatedly) realized the three finger salute was another
potential safety hazard, and added the AT BIOS int 15h intercept. Then PrtSc,
then the SysRequst key. Later on, we decided to attempt to translate all ASM
files over to (Borland extended) 'C', and from there to "all files compiled with
the -P (CPP always) command switch". The (slightly modified) result is file
CTRLC.C.
The basics, in psuedo-ASM. Initialize by hooking interrupt vectors
0x1B and 0x23 to routines similar to these:
public breakflag, new1Bh, new23h
.data
breakflag dw 0
.code
dGrp dw @data
proc setFlag near
push ds
mov ds, [dGrp] ; load flag segment
mov [breakflag], 1 ; set flag to boolean True
pop ds
ret
endp setFlag
proc new1Bh far
call setFlag ; go set flag
iret ; simple return to BIOS
endp new1Bh
proc new23h far
call setFlag ; go set flag
; sti ; this would work, usually, but sometimes
; clc ; failed under QEMM, EMM386, etc.
; ret 2 ; something to do with the interrupt flag
; in virtual 86 mode, we think
push bp ; this is more convoluted, but worked under
mov bp, sp ; QEMM, etc, without disturbing the int flag
push ax
mov ax, [bp+6] ; fetch flags from stack
and not 1 ; clearing carry tells DOS to continue
mov [bp+6], ax ; put adjusted flags back
pop ax ; restore & exit
pop bp
iret
endp new23h
The 'C' version of this formerly ASM file contains:
void init_kybd(); // install interrupt intercepts
void term_kybd(); // restore original interrupt vectors
Boolean breakflag; // set True when Ctrl-Break or Ctrl-C hit
Potential problems with our approach:
1. Supposedly, the infamous "Abort, Retry, Ignore, Fail" will abort
via int 23h. For us, that's not a problem, because we also intercept
int 24h (Critical Error), so we never abort, and never see this
message anyway. (See Borland's harderr(), hardretn(), etc)
2. In some cases that we haven't really chased down yet, MS-DOS v5.00
can and does remove a leading Ctrl-C from the keyboard buffer. This
has something to do with disk access, which is about the only dos calls
we make (Borland's memory calls during malloc(), etc are the others).
This is one reason we Ctrl-Break and Ctrl-C are still treated the same.
Note that our systems are multitaskers (preemptive and cooperative, and a BEAR
to debug sometimes !). The multitasker, window system, data input, serial
drivers, etc were all developed in-house (except Borland's run-time, and
Raima's dbVista). We access the hardware via BIOS when we can (keyboard, lpt's), directly when we need to
(video, aux's), and via DOS as a last resort (disk). All keyboard input calls
use the AT extensions to BIOS int 16h. Keyboard input is a relatively low
priority task.
!! WHAT WORKS FOR US MAY NOT MEET YOUR NEEDS !!
Obligatory legal stuff. These files are released into the public domain.
You may use them, modify them, etc to your heart's content. The author (me)
is NOT liable for any damages, lost profits, or any other problems caused by
your use of these routines. They work for us, so far, but you USE AT YOUR OWN
RISK !
(Whew. Ought to put that on a hot-key.)
Hope this is of some help. Questions are welcome, but may scroll off before
I can catch them (another road trip tomorrow). If you don't get an answer,
try again.
Roger Pittman [Jolly Roger :-)]
CI$ 74130,3011